Method and apparatus for quality of service management

ABSTRACT

A method for managing quality of service in a firewall server (110), the firewall server (11) coupling a data source to a data receiver, includes the steps of estimating a bit rate over a round-trip-time between the data source and the data receiver, receiving a receive acknowlegment signal from the data receiver, thereafter delaying transmission of a receive acknowlegment signal when the bit rate is greater than a bit rate limit, and transmitting the receive acknowlegment signal to the data source when the bit rate is not greater than the bit

CROSS-REFERENCE TO RELATED APPLICATIONS

This present application claims priority to U.S. Provisional ApplicationSer. No. 60/047,752 filed May 27, 1997, which is hereby incorporated byreference for all purposes.

BACKGROUND OF THE INVENTION

The present invention relates to communication or telecommunication.More particularly, the present invention provides a technique, includinga method and system, for monitoring and allocating bandwidth on atelecommunication network. As merely an example, the present inventionis implemented on a wide area network of computers or workstations suchas the Internet. But it would be recognized that the present inventionhas a much broader range of applicability including local area networks,a combination of wide and local area networks and the like.

Telecommunication techniques have been around for numerous years. In theearly days, people such as the American Indians communicated to eachother over long distances using "smoke signals." Smoke signals weregenerally used to transfer visual information from one geographicallocation to be observed at another geographical location. Since smokesignals could only be seen over a limited range of geographicaldistances, they were soon replaced by a communication technique known astelegraph. Telegraph generally transferred information from onegeographical location to another geographical location using electricalsignals in the form of "dots" and "dashes" over transmission lines. Anexample of commonly used electrical signals is Morse code. Telegraph hasbeen, for the most part, replaced by telephone. The telephone wasinvented by Alexander Graham Bell in the 1800s to transmit and sendvoice information using electrical analog signals over a telephone line,or more commonly a single twisted pair copper line. Most industrializedcountries today rely heavily upon telephone to facilitate communicationbetween businesses and people, in general.

In the 1990s, another significant development in the telecommunicationindustry occured. People began communicating to each other by way ofcomputers, which are coupled to the telephone lines or telephonenetwork. These computers or workstations coupled to each other cantransmit many types of information from one geographical location toanother geographical location. This information can be in the form ofvoice, video, and data, which have been commonly termed as "multimedia."Information transmitted over the Internet or Internet "traffic" hasincreased dramatically in recent years. In fact, the increased traffichas caused congestion, which leads to problems in responsiveness andthroughput. This congestion is similar to the congestion of automobileson a freeway, such as those in Silicon Valley from the recent "boom" inhigh technology companies, including companies specializing intelecommunication. As a result, individual users, businesses, and othershave been spending more time waiting for information, and less time onproductive activities. For example, a typical user of the Internet mayspend a great deal of time attempting to view selected sites, which arecommonly referred to as "Websites," on the Internet. Additionally,information being sent from one site to another through electronic mail,which is termed "email," may not reach its destination in a timely oradequate manner. In effect, quality of service or Quality of Service("QoS") of the Internet has decreased to the point where some messagesare being read at some time significantly beyond the time the messageswere sent.

Quality of Service is often measured by responsiveness, including theamount of time spent waiting for images, texts, and other data to betransferred, and by throughput of data across the Internet, and thelike. Other aspects may be application specific, for example, jitter,quality of playback, quality of data transferred across the Internet,and the like. Three main sources of data latency include: the lack ofbandwidth at the user (or receiving) end, the general congestion ofInternet, and the lack of bandwidth at the source (or sending) end.

A solution to decreasing data latency includes increasing the bandwidthof the user. This is typically accomplished by upgrading the networklink, for example by upgrading a modem or network connection. Forexample, the network link may be upgraded to X2 modems, 56K modems, ADSLor DMT modems, ISDN service and modems, cable TV service and modems, andthe like. Drawbacks to these solutions include that they typicallyrequire additional network service; they also require additionalhardware and/or software, and further they require both the sender andreceiver to both agree on using the same hardware and/or software.Although one user may have a much faster line or faster modem, anotheruser may still rely on the same 1,200 kbaud modem. So, the speed atwhich information moves from one location to another location is oftendetermined by the slowest information which is being transferred overthe network. Accordingly, users of faster technology are basically goingnowhere, or "running" nowhere fast, as is commonly stated in the networkindustry.

From the above, it is seen that a technique for improving the use of awide area network is highly desirable.

SUMMARY OF THE INVENTION

The present invention relates to a technique, including a method andsystem, for providing more quality to telecommunication services on anetwork. More particularly, the present invention relates to quality ofservice management using computer network firewalls and software tools.

In a specific embodiment, the present invention provides a noveltechnique for rate control and quality of service ("QoS") management forboth inbound and outbound transmission control protocol/Internetprotocol ("TCP/IP") traffic at a gateway. The techniques are implementedwithin a network firewall platform using novel measurement techniques.Rate control (flow control) of inbound TCP traffic at the gateway iseffected by the filtering of data packet acknowledgments ("ACKs") andinvoking TCP's native source flow control. All conventional semantics ofTCP flow control such as `silly-window` are supported to ensurecompatibility with systems conforming to TCP standards. Rate controlalso applies to Outbound TCP traffic.

The above technique is preferably implemented at a computer networkfirewall using ACKs as a timing mechanism. Preferably rate control isinvoked when inbound or outbound traffic increases over defined limitsor at selected values. Measurement of Inbound traffic is preferablyperformed with two techniques: first, a sliding window estimation of bitrates over a mean round-trip-time for both connections and connectionclasses (aggregates); and second, an emulation of weighted fair queuingfor inbound traffic, that provides measures on which inbound class orconnection needs to be rate controlled. In response to the abovetechniques, the inbound traffic is treated as though a QoS system werein place at the sending end of the link.

According to an alternative embodiment, the present invention provides anovel method for managing quality of service in a firewall server. Thefirewall server is coupled to a data source, which is coupled to a datareceiver. The present method includes steps of estimating a bit rateover a round-trip-time between the data source and the data receiver andreceiving a receive acknowledgment signal from the data receiver.Thereafter, a step of delaying transmission of a receive acknowledgmentsignal when the bit rate is greater than a bit rate limit is included.The method also transmits the receive acknowledgment signal to the datasource when the bit rate is not greater than the bit rate limit. Thissequence of steps are used to manage data at, for example, the firewallserver location.

According to another embodiment, the present invention includes, amongother elements, a novel computer program product for a firewall server.The firewall server has a processor for managing quality of service andalso has a computer-readable memory including a variety of codes. In oneembodiment, the code directs the processor to estimate a bit rate over around-trip-time between the data source and the data receiver. The codealso directs the processor to receive a receive acknowledgment signalfrom the data receiver. Additionally, the computer-readable memoryincludes code that directs the processor to delay transmission of thereceive acknowledgment signal when the bit rate is greater than a bitrate limit, and code the directs the processor to transmit the receiveacknowledgment signal to the data source when the bit rate is notgreater than the bit rate limit. The computer memory can also include avariety of other codes based upon the techniques described herein.

Numerous advantages are achieved by way of the present invention overpre-existing or conventional techniques. In a specific embodiment, thepresent invention provides a single point or a single region to managetelecommunication traffic including directory services and "bandwidthmanagement." Additionally, in some, if not all embodiments, the presentinvention can be implemented at a single point of access such as acomputer terminal or firewall, for example. Furthermore, the presentinvention can be predominately software based and can be implementedinto a pre-existing system by way of a relatively simple installationprocess. These and other advantages are described throughout the presentspecification, and more particularly below.

Further understanding of the nature and advantages of the invention maybe realized by reference to the remaining portions of the specification,drawings, and attached documents

BRIEF DESCRIPTION OF THE DRAWINGS

FIG. 1 illustrates a simplified system including an embodiment of thepresent invention;

FIG. 2 is a simplified block diagram of a firewall server according toan embodiment of the present invention;

FIG. 3 illustrates an example of a simplified hierarchical model fordetermining bandwidth sharing;

FIG. 4 illustrates a simplified table summarizing some basic TCP/IPtraffic classes and typical policies that are applied to them;

FIG. 5 illustrates a simplified block diagram of a flow chart accordingto an embodiment of the present invention;

FIG. 6 illustrates a simplified state transition diagram for anembodiment of the present invention; and

FIG. 7 illustrates an implementation architecture of an embodiment ofthe present invention.

DESCRIPTION OF SPECIFIC EMBODIMENTS

An embodiment of the present invention provides integrated networkservice policies for firewall platforms. Specifically, the presentinvention provides network or firewall administrators with the abilityto implement policy-based schema for security and resource management onfirewall platforms. In a specific embodiment, resource managementincludes Network Quality of Service (QoS) or "bandwidth" managementtechniques.

Network QoS occurs by managing the resources that serve networkapplication traffic, for example. This typically includes the followingresources: link bandwidth; application server bandwidth (CPU); andbuffer space on generally all nodes (e.g., end-points, routers andgateways). Typically, data through-put is limited by the speed ofInternet access links and by the server CPU capacity, and response timeis determined by the number of hops in a route, physical length of theroute, and extent of congestion in the route. There are various otherfactors that may affect QoS, such as the behavior of TCP/IP, severecongestion anywhere in the route, prioritization of traffic along theroute, etc. To a network administrator, embodiments of the presentinvention provide discrimination of different traffic types and providemethods for enforcement of traffic flow by management to the aboveresources.

I. System Overview

FIG. 1 illustrates a simplified system 100 including an embodiment ofthe present invention. The system 100 is merely an illustration andshould not limit the scope of the claims herein. One of ordinary skillin the art would recognize other variations, modifications, andalternatives. The present invention can be embodied as TrafficWare™firewall server 110 from Ukiah Software, Inc, but can be others. System100 typically includes a file server 120, and a plurality of computers130-150, coupled to a local area network (LAN) 160, and other elements.Firewall server 110 includes a typical connection to a wide area network(WAN) 170 and to a remote LAN 180 (such as an Intranet) and a typicalnetwork connection 190 to the Internet 200. Attached to Internet 200 areWeb servers 210 and other computers 220.

As illustrated, computers such as computer 130, 140, and 210 communicateusing any one or multiple application layer protocols such as Telnet,file transfer protocol (FTP), Hypertext transmission protocol (HTTP),and the like. Further, communication across WAN 170 and across networkconnection 190 implements transport layer protocols such as transmissioncontrol protocol (TCP), universal data protocol (UDP), and the like. LAN160 and LAN 180 are preferably based upon network protocols such asInternet protocol (IP), IPX from Novell, AppleTalk, and the like. Asshown in FIG. 1, network connection 190 may be accomplished using T1,ISDN, Dial-up, and other hardware connections. Computers 120-150 and210-220 may be any suitable make or model of computer that can becoupled to a network. The system can also include a variety of otherelements such as bridges, routers, and the like.

FIG. 2 is a simplified block diagram of a firewall server 300 accordingto an embodiment of the present invention. The block diagram is merelyan illustration and should not limit the scope of the claims herein.Firewall server 300 typically includes, among other elements, a monitor310, a computer 320, a keyboard 330, a graphical input device 340, and anetwork interface 350. Computer 320 includes familiar computercomponents such as a processor 360, and memory storage devices, such asa random access memory (RAM) 370, a disk drive 380, and a system bus 390interconnecting the above components. A external network connection 400and an internal network connection 410 are coupled to network interface350.

A mouse is but one example of graphical input device 340, also known asa pointing device, a trackball is another. RAM 370 and disk drive 380are examples of tangible media for storage of computer programs such asembodiments of the herein described invention. Other types of tangiblemedia include floppy disks, removable hard disks, optical storage mediasuch as CD-ROMS and bar codes, semiconductor memories such as flashmemories, ASICs, read-only-memories (ROMS), battery-backed volatilememories, and the like. External network connection 400 typicallyprovides access to external networks such as LAN 180 or Internet 200, asdescribed in FIG. 1. Internal network connection 410 typically providesaccess to internal networks such as LAN 160.

In a specific embodiment, firewall server 300 includes a IBM PCcompatible computer having a '586-class based microprocessor, such aPentium™ from Intel Corporation, running WindowsNT™ from MicrosoftCorporation, and TrafficWare™ software from Ukiah Software, Inc. Networkinterface 350 is preferably embodied as a hardware firewall server alsofrom Ukiah Software, Inc., but can be others.

FIG. 2 is representative of but one type of system for embodying thepresent invention. It will be readily apparent to one of ordinary skillin the art that many system types and software configurations aresuitable for use in conjunction with present invention. The presentinvention can be in the form of software in one embodiment.Alternatively, the present invention can be a combination of hardwareand software, which can be further combined or even separated. Ofcourse, the particular type of system used in the present inventiondepends highly upon the application.

II. Outbound Control

1. Traffic Classes

An embodiment of the present invention discriminates between trafficclasses or traffic types. For example, between application/protocol(e.g., HTTP, SMTP, FTP, Telnet), data-type (e.g., MIME type, HTML, JPEG,RealAudio, .WAV, .MOV), source/destination identifier (e.g., IP address,user name, domain, URQ), type (real-time, interactive,throughput-intense), direction (inbound/outbound), and the like. Furthertraffic classes are based upon specifics user (e.g., President, ShippingClerk), business group (e.g., Sales, Engineering, Accounting), priority(e.g., user-determined priority levels), direction (e.g., inbound,outbound, customer, guest).

FIG. 3 illustrates an example of a hierarchical model for determiningbandwidth sharing. This model is merely an illustration and should notlimit the scope of the claims herein. As illustrated in FIG. 3, ahierarchical model is represented as a tree, with the root representingthe total available bandwidth, each branch node representing aggregatedtraffic (meta-traffic classes), and the leaves representing individualconnections (traffic classes). This model gives the user flexibility indefining and implementing a service policy or multiple service policies.For example, the network traffic is first divided in different ways andthen the specific policy refined from a top down approach or amalgamatedfrom a bottom up approach. This model also provides the user withdifferent methods for different traffic classes since it abstracts thepolicy definition from the enforcement or implementation.

The user typically has competing factors to consider when determining anetwork QoS policy, including bandwidth "guarantees", latency"guarantees", and exception control. It should be understood"guarantees" refer to best efforts of the system to provide service, anddoes not in any way imply an absolute guarantee of service. For example,obviously no service can be provided or guaranteed if the networkconnection is inoperative, if the Internet Service Provider (ISP) hashardware or software glitches, or there is a general Internet crash.

A first factor is bandwidth guarantee, or data throughput guarantee, andhow excess bandwidth is shared. For traffic classes that have dataintensive requirements this is an important criteria. Typically, theuser initially determines what are the minimum bandwidth guarantees thatare given for different traffic classes or for connections relying ondata from the different traffic classes, before determining a policy. Asresult of the policy, the system monitors the actual bandwidth providedto different classes, and preferably if bandwidth is critically low, thesystem attempts to provide at least the minimum bandwidth to thedifferent traffic classes.

Typically, the user also initially determines how excess bandwidth isallocated. In a hierarchical model, the user provides bandwidth sharingby classes `passing up` or `receiving` unused bandwidth via their`parents`. As a result, closer siblings (traffic classes) typically areable to share more bandwidth than distant traffic classes.Alternatively, the user may decide that all leaf classes are allowed toutilize excess bandwidth simply based on their priority.

A second factor is latency guarantees, or response time guarantees. Fortraffic classes that are sensitive to delays this is an importantcriteria. Typically latency is determined by the end-end route ratherthan the local network or any single gateway. The user typically firstdetermines what are the maximum latency guarantees that are given fordifferent traffic classes, before determining a policy. In response tothe policy, the system monitors the bandwidth provided to differentclasses and if a particular traffic class requires a quicker response,the system attempts to provide more bandwidth for that traffic class.This monitoring occurs preferably when the network is idle or when thenetwork is congested.

A third factor is exception control. The system preferably implementsexception control when the bandwidth link capacity is being exceeded(congestion) or when a traffic class is attempting to exceed it'sallotted capacity. Initially, the user typically determines what actionsto perform when there are exceptions, some actions include: admissioncontrol (e.g., deny new requests), service degradation (e.g., droppingpackets), sources throttling, traffic redirection (load sharing), andthe like. Exception control is preferably a function of traffic type andpolicy. For example, the user may determine that real-time videorequires a steady bit-rate and thus requires admission control as anexception policy when the bandwidth is low, and the user may determinethat bulk file download services (which are weakly interactive) mayaccommodate some new requests thus instruct the system to throttle thedownload sources when the bandwidth is low.

The user is preferably provided with three properties: bandwidthintensive, real-time and/or interactive, which are useful in describingmeaningful policies for the different traffic classes. Bandwidth-intensetraffic classes typically require relatively large transmission rates(>50 kbps) for each connection over short or long intervals to maintainreasonable quality. Interactive classes typically require a low latencyfor all packets to maintain a good response time. Real-time classestypically require a very steady rate of data delivery (high or low) andgenerally also low latency. These three properties or combinations ofthem can also be thought of as describing generic (base) classes oftraffic.

FIG. 4 illustrates a table summarizing some basic TCP/IP traffic classesand typical policies that are applied to them. As show, traffic classessuch as HTTP, HTML, GIF, JPEG, RealAudio, Realtine Video, SMTP, NNTP,FTP, TELNET, DNS, RPC, Novell NCP are shown. To these classes, a baseclass is given. Applied policy and exception control are also provided,for example. Other combinations or assignments of the above policies maybe made in alternative embodiments of the present invention. Further, inFIG. 4, `P` represents dependence upon a specific policy implemented bythe user.

2. Packet Scheduling

The system allocates output bandwidth per traffic class preferably byusing a class of scheduling methods referred to as fair queuingalgorithms at the firewall. These algorithms model traffic as weightedflows and attempt to ensure that service is given to all flows (trafficclasses) in proportion to their assigned minimum bandwidth. Servicetypically occurs in a round robin fashion while monitoring the maximumdelays. The system preferably combines such methods with priority basedschedulers in order to provide latency guarantees. These types ofoutbound flows systems typically apply localized control over all timeintervals, are generally efficient to implement, provide good linkutilization, and do not depend on protocol or connection semantics.

Outbound flow control as described above is preferably combined withTCP/IP rate control, described below.

III. Source Control

In an embodiment of the present invention, rate control policies arespecified in the form of a bandwidth allocation hierarchy, as describedabove, that defines aggregates of traffic according to user-specifiedparameters (e.g., application type, MIME type or source/destination ID).Further, classes are either guaranteed or best-effort.

As described above, inbound flows may have guaranteed classes thatinclude a minimum reserved rate per connection and preferably havelimits on the total bandwidth used or number of simultaneous guaranteedconnections. Preferably, the remainder of the bandwidth, including anyexcess from the guaranteed classes, is dynamically allocated to`best-effort` classes, and new best-effort connections. The specificallocation and policy are user definable. In the preferred embodiment,classes that flow above their rate limits are subject to rate controlpreferably if there is demand from siblings, either in the form of newconnection requests.

IV. TCP/IP Flow Control

Flow control behavior refers to having end-points adjust their transferrates in response to congestion indicators or under gateway control.This applies to both inbound and outbound traffic. In the preferredembodiment, the end-points implement TCP/IP.

TCP flow control uses the concept of "window size" to enable a receiverendpoint to indicate how much data the source end-point can send in aburst at any given time. To do this, the receiver transmits a windowsize limit to the source. TCP utilizes timeouts and duplicateacknowledgment signals (ACKs) to initially determine network congestion,and then utilizes the concept of window size as a tool to prevent andrespond to the congestion, To do all this accurately and efficiently,TCP uses a half-dozen subtly intertwined algorithms. Congestion controlis done reactively and coarsely and typically involves long delays andretransmitted traffic on the network. ACKs are used to avoid overallnetwork collapse.

In an embodiment, a gateway at the route bottleneck (e.g., the Internetaccess line) is used to invoke this window size flow control mechanismin a proactive manner by screening bandwidth use and updating thesources. Typically, control applies over relatively large time scales(typical Internet round-trip times).

In alternative embodiments of the present invention, ICMP SourceQuenching can also be used to serve as a flow control mechanism. ICMPSource Quenching is an IP mechanism typically invoked by routers toindicate buffer overflow. BSD based TCP/IP stacks will effect a sharpbacking off of TCP data traffic bursts on receipt of such ICMP packets.

To achieve control over inbound traffic, the present invention invokesflow control at the source to spoof window size packets. This techniqueis also applied as a high-level control over the outbound fair schedulerin order to control congestion preferably when traffic is not subject toadmission control. Further, a fair scheduler for inbound communicationsis used to identify which classes may need to be controlled at thesource.

FIG. 5 illustrates a simplified block diagram of a flow chart accordingto an embodiment of the present invention. Initially, a TCP connectionrequest (SYN) is classified into the user-specified class hierarchy,step 500. A connection is fully classified if it can be assigned to aleaf node. The connection is partially classified if it cannot beuniquely assigned to a non-leaf node. A connection may not be fullyclassified until the arrival of the first request-data packet.

Next, during connection setup, the round-trip-time (RTT) of theconnection is estimated, step 510. The RTT is typically not reliablymeasured during windowed data flow at a gateway without probe packets orrouting information. Thus, the present method typically does not dependon accurate measures of RTT but rather is driven by a nominal value fromthe first estimate.

At any given time, the available response-data bandwidth is partitionedto all existing connections within a class proportionally. The availablebandwidth is updated upon each new admitted connection (SYN or SYN&DATA)and each terminated connection (FIN). If there are guaranteed rates foreach connection, the system may disallow new connections duringrequest-data phase or allow new connections as a best-effort class.

The source is then allowed to ramp up the source flow according toapplication requirements and TCP flow control, step 520. This flow ismonitored by monitoring ACKs flowing in the return direction. Duringthis phase, the system also estimates the bottleneck link speed for theconnection. As a result, the minimum inter-ACK, back-to-back ACKs, orinter-data packet time observed is determined, step 530, which gives alower bound on link speed. This speed is typically used to adjust andreallocate source bandwidth among sibling connections preferably if theavailable rate is greater than the link speed.

In a preferred embodiment, on each data ACK, the available responsebandwidth and actual utilization over the life of the connection istranslated into a limit window size for the next RTT, step 540. In analternative embodiment, fair queuing at all leaf nodes and the uselimiting queue lengths are used to calculate window sizes. A limitwindow increase is scaled to a multiple of the segment size to emulatereceiver silly-window avoidance.

If the connection ramps above the assigned source flow (or the emulatedfair queue grows too large), step 550, the window sizes are preferablymodified with each response ACK as follows, step 560:

If(wsender>wmax) {w=MAX(wmax, MSS); if(a+w<eprev) {w=eprev-a} else{eprev=e }; send-ack(a, w) }

Where MSS=Max. segment size; eprev=Window right edge sequence#advertised in previous ACK; wsender=Window advertised by the sender;a=ACK sequence #; wmax=Window size limit; and w=sent window.

The above rate control method is efficient to implement, follows TCPsemantics (including silly window avoidance and window updates), and"guarantees" a minimum bandwidth (MSS/RTT) to a connection without useof any timing or queuing mechanisms. The method is extendable to providearbitrarily small bandwidth limits using a timing or queuing mechanismto send a window update preferably as follows:

If(wmax<MSS) {set₋₋ timer(RTT*MSS/wmax) } timer: w=MSS; send₋₋ ack(a,w)

The above equations are merely exemplary, it should be understood thatmany variations in the above equations can be made in light of theteaching above are such variations are contemplated in alternativeembodiments of the present invention. In the preferred embodiment, tocompensate for the effects of TCP slow-start, a connection sends up to25% over limit over any RTT.

FIG. 6 illustrates a simplified state transition diagram for anembodiment of the present invention. FIG. 6 illustrates the role oftraffic class and policy in one embodiment of the present invention.Typically, when a traffic class for a connection is not recognized, whenexception conditions are in place, and other situations, a connection isnot admitted, state 600. If a connection is admitted, state 610, datacan then begin to flow, state 620.

FIG. 6 further illustrates how typically TCP flow is not inhibited whenthe round-trip-time does not exceed the flow limits, state 620, and howtypical TCP flow is inhibited when the round-trip-time exceeds the flowlimits, state 630. In the former case, the ACK signal is typically notinhibited, whereas in the latter case, the ACK signal is inhibited, ordelayed.

FIG. 7 illustrates an implementation architecture of an embodiment ofthe present invention.

V. Applications

The embodiments described above are preferably used to address currentand future technological changes and requirements.

For example, the embodiments of the present invention provide resourcemanagement for ever increasing traffic, i.e. scalability. Scaling refersto the growing (and often indeterminate) body of users having widelyvarying access speeds that compete for the same resources, for examplebandwidth. Scaling is adversely affected by the growing volume ofavailable content (e.g. HTML pages), by the falling costs of CPUs, andtrends towards network computers. By providing QoS management, asdescribed above, management of increasingly scarce resources (bandwidth)is facilitated.

Further, the embodiments of the present invention provide resourcemanagement to respond to Business priorities. Business use of theInternet typically ranges from casual use to business critical use. Assecure Internet business applications continue to develop, providingservice quality for these core business functions over casual use willbe a high priority (e.g., the quality of external access of a customerto an order entry web page. By providing QoS management as describedabove, Business-oriented or other priority traffic is facilitated.

Also the embodiments of the present invention provide resourcemanagement to respond to different traffic types. As different types ofcontent application increase and standards continue to emerge andevolve, different types of Internet traffic may require specific serviceguarantee. For example, different applications may require differentbandwidth, e.g. intensive, real-time, interactive, and the like. Byproviding QoS management as described above, bandwidth critical trafficis facilitated.

The embodiments of the present invention described above preferablyprovide a symmetrical, solution for gateway control of inbound andoutbound traffic over the Internet, with the basic methods (queuing andsource TCP rate control) designed to complement each other.

Conclusion

In the foregoing specification, the invention has been described withreference to specific exemplary embodiments thereof Many changes ormodifications are readily envisioned. For example, the present inventioncan be applied to manage a variety of TCP/IP network traffic types forthe Internet and Intranet. Further, the techniques can also be appliedto Novell SPX, Xerox XNS or any protocol with a similar `flow-control`design that utilizes windows and acknowledgment signals (similar toACK).

Alternative embodiments of the present invention can also be applied toa `legacy` private WAN running IP as well as native Novell protocols ifthere is a need. (e.g., file server and client/server traffic). Further,embodiments of the present invention can include monitoring, billing,and reporting features, thus allowing for enhanced client billing andinternal cost accounting of network usage.

These techniques are preferably implemented within a firewall platformto solve the provide the following benefits: bidirectional bandwidthmanagement of network links carrying TCP traffic; reactive (short-timescale) and proactive (long time scale) control mechanisms; and gateway(local) and end-end (global) techniques for bandwidth control. Thissolution reduces their contribution to congestion in the Internet; andoperation in a present day heterogeneous wide area networks, such as theInternet, without requiring any client, server or router changes.

The specification and drawings are, accordingly, to be regarded in anillustrative rather than a restrictive sense. It will, however, beevident that various modifications and changes may be made thereuntowithout departing from the broader spirit and scope of the invention asset forth in the claims.

What is claimed is:
 1. A method for managing quality of service in afirewall server, the firewall server coupling a data source to a datareceiver, comprising:classifying a connection between the data sourceand the data receiver into at least one traffic class from a pluralityof traffic classes; estimating a bit rate over a round-trip-time betweenthe data source and the data receiver at the firewall server; receivinga receive acknowledgment signal from the data receiver; delayingtransmission of a receive acknowledgment signal when the bit rate isgreater than a bit rate limit; and transmitting the receiveacknowledgment signal to the data source when the bit rate is notgreater than the bit rate limit.
 2. The method of claim 1 wherein thedata source and the data receiver communicate using TCP, and theacknowledge signal is the ACK signal.
 3. The method of claim 1 furthercomprising determining the bit rate limit.
 4. The method of claim 3wherein the bit rate limit is for the data source.
 5. The method ofclaim 3 wherein the bit rate limit is for the data receiver.
 6. Themethod of claim 1 further comprising determining the bit rate over around-trip-time between the data source and the data receiver beforetransmitting the receive acknowledgment.
 7. The method of claim 1wherein traffic classes in the plurality of traffic classes areuser-definable.
 8. The method of claim 1 wherein classifying theconnection between the data source and the data receivercomprises:determining a characteristic of data transmitted from the datasource to the data receiver via the connection; and classifying theconnection based on the data characteristic.
 9. The method of claim 8wherein the data characteristic is selectable from a group of datacharacteristics including data protocol, data application, data-type,source of the data, destination of the data, direction of the data, anduser-defined data characteristics.
 10. A firewall server for managingquality of service comprising:a computer memory; classifying meanscoupled to the computer memory for classifying a connection between adata source and a data receiver into at least one traffic class from aplurality of traffic classes; estimating means coupled to the computermemory for estimating a bit rate over a round-trip-time between the datasource and the data receiver; receiving means for receiving a receiveacknowledgment signal from the data receiver; delay means for delayingtransmission of the receive acknowledgment signal when the bit rate isgreater than a bit rate limit; and transmitting means for transmittingthe receive acknowledgment signal to the data source when the bit rateis not greater than the bit rate limit.
 11. A computer program productfor a firewall server including a processor for managing quality ofservice comprising:a computer-readable memory comprising:code thatdirects the processor to classify a connection between a data source anda data receiver into at least one traffic class from a plurality oftraffic classes; code that directs the processor to estimate a bit rateover a round-trip-time between the data source and the data receiver;code that directs the processor to receive a receive acknowledgmentsignal from the data receiver; code that directs the processor to delaytransmission of the receive acknowledgment signal when the bit rate isgreater than a bit rate limit; and code that directs the processor totransmit the receive acknowledgment signal to the data source when thebit rate is not greater than the bit rate limit.
 12. A method formanaging network traffic in a network, the network conforming to TCPprotocol, comprising:determining a plurality of traffic classes for thenetwork traffic, each traffic class having a priority; forming ascheduling of transmissions of the network traffic according to thepriority of each traffic class; and using TCP flow control to limit theflow of the network traffic according to the schedule.
 13. The method ofclaim 12 wherein the network traffic is outbound network traffic. 14.The method of claim 12 wherein the network traffic is inbound networktraffic.
 15. The method of claim 12 wherein the plurality of trafficclasses is determined in response to a network traffic type.
 16. Themethod of claim 12 where network traffic types includes file types. 17.The method of claim 12 wherein the plurality of traffic classes isdetermined in response to a network traffic source.
 18. The method ofclaim 12 wherein network traffic sources includes business units. 19.The method of claim 12 wherein the plurality of traffic classes isdetermined in response to a network traffic requirement.